Please address the comments from this code review:

## Overall Comments
- In the `_query_stream` error handler you now log the entire `chunk` object at warning level with `exc_info=True`; consider either truncating/structuring this data or lowering it to debug to avoid excessively large logs and potential leakage of sensitive content.
- The new empty-response fallback condition in `_iter_llm_responses_with_fallback` only checks `resp.completion_text` and `resp.tools_call_args`; if other non-textual outputs (e.g., images, function call ids, or metadata) can represent a valid reply, you may want to include them in the emptiness check to avoid incorrectly triggering fallback.

## Individual Comments

### Comment 1
<location path="astrbot/core/provider/sources/openai_source.py" line_range="318-324" />
<code_context>
+                            if tool_call.type is None:
+                                tool_call.type = "function"
+
             try:
                 state.handle_chunk(chunk)
             except Exception as e:
-                logger.warning("Saving chunk state error: " + str(e))
+                logger.warning(
+                    f"Saving chunk state error: {type(e).__name__}: {e}. Chunk data: {chunk}",
+                    exc_info=True,
+                )
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Logging full chunk objects on errors may be heavy and potentially sensitive; consider truncating or summarizing.

Logging the full `chunk` can inflate log volume and may include user content you don’t want stored verbatim. Consider logging a truncated/summary view (e.g., `repr(chunk)[:N]` or just key identifiers) or moving the full payload behind a debug-level log, while keeping the exception type/message at warning level.

```suggestion
            try:
                state.handle_chunk(chunk)
            except Exception as e:
                # Log a truncated summary of the chunk at warning level to avoid
                # excessive log volume and potential sensitive data exposure.
                max_chunk_log_len = 500
                chunk_repr = repr(chunk)
                if len(chunk_repr) > max_chunk_log_len:
                    chunk_repr = chunk_repr[:max_chunk_log_len] + "... [truncated]"
                logger.warning(
                    "Saving chunk state error: %s: %s. Chunk summary (repr, max %d chars): %s",
                    type(e).__name__,
                    e,
                    max_chunk_log_len,
                    chunk_repr,
                    exc_info=True,
                )
                # Keep full payload only at debug level for deeper troubleshooting.
                logger.debug("Full chunk data for error: %r", chunk, exc_info=True)
```
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- When normalizing `tool_call.type` in `openai_source._query_stream`, consider only forcing it to `'function'` if the SDK object actually has a `function` payload (e.g. `tool_call.function is not None`) so that future non-`function` tool types or other extensions are not inadvertently masked.
- The `_is_empty_llm_response` heuristic currently ignores `resp.role`; if the provider ever returns error-like responses with empty text but `role != 'assistant'`, you may want to special-case those to avoid incorrectly treating them as empty assistant replies and triggering fallback.

Please address the comments from this code review:

## Overall Comments
- Consider reusing `_is_empty_llm_response` in the `step()` empty-assistant check instead of duplicating the empty-response heuristic so behavior stays consistent if the heuristic is updated later.
- When logging the empty-response fallback in `_iter_llm_responses_with_fallback`, you might include model/provider identifiers (similar to the new logging in `openai_source.py`) to make it easier to trace which upstream returned the empty reply.
- The debug log for each chunk with missing `tool_call.type` in `_query_stream` could become noisy for long streams; consider logging only once per stream or at a lower verbosity level after the first occurrence.

Please address the comments from this code review:

## Overall Comments
- In `_is_empty_llm_response`, all non-`Comp.Plain` components are treated as meaningful content; if there are metadata-only component types in `result_chain`, consider whitelisting which component types count as meaningful to avoid suppressing fallback on structurally empty but non-plain chunks.
- In `OpenAISource._query_stream`, the hard-coded string `"function"` for `tool_call.type` could be replaced with a shared constant or SDK enum (if available) to avoid drift if the underlying type values change and to make the intent clearer.

## Individual Comments

### Comment 1
<location path="astrbot/core/provider/sources/openai_source.py" line_range="332-338" />
<code_context>
             has_stream_output = False
             try:
                 async for resp in self._iter_llm_responses(include_model=idx == 0):
+                    # 对于流式 chunk，不立即检查是否为空，因为单个 chunk 可能只是元数据/心跳
</code_context>
<issue_to_address>
**suggestion:** Use logger.exception (or include exc_info) to preserve the traceback when chunk handling fails.

Only the exception message is currently logged, which makes diagnosing protocol/stream issues harder. Please log with traceback, e.g.:

```python
try:
    state.handle_chunk(chunk)
except Exception:
    logger.exception(
        "[%s] Saving chunk state error (provider: %s)",
        self.get_model(),
        self.provider_config.get("id", "unknown"),
    )
```

This keeps the model/provider context while exposing the full stack trace.

```suggestion
            try:
                state.handle_chunk(chunk)
            except Exception:
                logger.exception(
                    "[%s] Saving chunk state error (provider: %s)",
                    self.get_model(),
                    self.provider_config.get("id", "unknown"),
                )
```
</issue_to_address>

### Comment 2
<location path="astrbot/core/agent/runners/tool_loop_agent_runner.py" line_range="224" />
<code_context>
         else:
             yield await self.provider.text_chat(**payload)

+    def _is_empty_llm_response(self, resp: LLMResponse) -> bool:
+        """Check if an LLM response is effectively empty.
+
</code_context>
<issue_to_address>
**issue (complexity):** Consider decomposing the new empty-response handling into smaller helpers and named booleans to keep the behavior while simplifying control flow and readability.

You can keep the new behavior but reduce control-flow complexity by splitting responsibilities and using more declarative helpers.

**1. Decompose `_is_empty_llm_response` and simplify the loop**

Instead of manual flag mutation and a mixed-responsibility helper, you can factor it into smaller helpers and use `any()`:

```python
def _has_text_content(self, resp: LLMResponse) -> bool:
    return bool((resp.completion_text or "").strip() or (resp.reasoning_content or "").strip())

def _has_result_chain_content(self, resp: LLMResponse) -> bool:
    if not resp.result_chain or not resp.result_chain.chain:
        return False

    return any(
        (
            isinstance(comp, Comp.Plain) and bool(comp.text and comp.text.strip())
        ) or (
            not isinstance(comp, Comp.Plain)  # non-Plain components are valid content
        )
        for comp in resp.result_chain.chain
    )

def _is_empty_llm_response(self, resp: LLMResponse) -> bool:
    return (
        not self._has_text_content(resp)
        and not resp.tools_call_args
        and not self._has_result_chain_content(resp)
    )
```

This keeps the semantics but flattens branching and makes each rule independently testable.

**2. Name the boolean parts of the fallback condition**

The compound `if` in `_iter_llm_responses_with_fallback` becomes easier to scan if intermediate booleans are named:

```python
is_assistant_or_tool = resp.role in ("assistant", "tool")
is_empty = self._is_empty_llm_response(resp)
should_try_fallback = is_assistant_or_tool and is_empty and not is_last_candidate

if should_try_fallback:
    logger.warning(
        "Chat Model %s returns empty response, trying fallback to next provider.",
        candidate_id,
    )
    break
```

This preserves the logic but improves readability.

**3. Compact error context construction**

The error construction in `step` can be tightened while keeping the same context in the message:

```python
base_msg = "LLM returned empty assistant message with no tool calls."
ctx = {
    "model_id": getattr(self.run_context, "model_id", None),
    "provider_id": getattr(self.run_context, "provider_id", None),
    "run_id": getattr(self.run_context, "run_id", None),
}
context_str = ", ".join(f"{k}={v}" for k, v in ctx.items() if v is not None)
if context_str:
    base_msg = f"{base_msg} Context: {context_str}."
raise LLMEmptyResponseError(base_msg)
```

If you expect to reuse this pattern elsewhere, you could move it into a small `_format_empty_response_error()` helper, but even this inline version makes the branch visually lighter.
</issue_to_address>